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(54) Method for reserving resources 

(57) A method for managing resources in a compu- 
ter system. 

According to one embodiment of the invention, a re- 
source manager receives a first request of a first oper- 
ation. The first request identifies a first resource and 
specifies an amount of the first resource needed to ex- 
ecute the first operation. In response, a resource man- 



ager determines if the amount of the first resource re- 
quested by the first request is available to be resen/ed. 
In response to the amount of the first resource request- 
ed by the first request being available to be reserved, 
the resource manager reserves the amount of the first 
resource requested by the first request in advance of 
allocating the first resource to the first operation. 
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Description 

FIELD OF THE INVENTION 

The present invention relates to computer systems, 
and, in particular, to reserving and managing computer 
system resources. 

BACKGROUND OF THE INVENTION 

In computing environments such as embedded sys- 
tems, set-top boxes, or general purpose computers 
where resources (e.g. memory) are limited, software is 
developed to accommodate the uncertainty of whether 
resources needed tocomplele an operation will be avail- 
able. 

For general purpose computers, well written soft- 
ware requests resources as they become needed and 
verifies that the requested resources were actually pro- 
vided. If it is determined that a resources was not pro- 
vided, the operation being performed is aborted part- 
way through, and any resources allocated in earlier 
stages of the operation are returned to the system. 

In a system with scarce resources, however, this 
approach does not perform well. For example, tf (here 
are only enough resources available for one operation 
to execute until completion, but the system begins two 
operations, both operations may fail halfway through. 

Some systems attempt to solve this problem by 
dedicating pools of resources for specific operations 
This approach also has problems. 

Consider the example that we have two operations. 
A and B. Each operation is only allocated 100 bytes of 
memory. Further consider the case where opernlion A 
is not using its 100 bytes of memory and B needs 150 
bytes of memory. Even though the 200 bytes of memory 
are available in the system, operation B cannot proceed 
since 100 bytes of the systems memory are only avail- 
able to operation A. 

Some programmers attempt to solve this problem 
by preallocaling resources. For example, if a program- 
mer knows that they need lOO bytes of meinory at the 
start of an operation, another 100 bytes halfway 
through, and 100 bytes at the end of the operation, then 
the programmer would allocate 300 bytes ol memory 
before beginning the operation. 

Preallocaling resources, however, has at least 
three' drawbacks. First, in an object oriented environ- 
ment, there may be no way to allocate resources of the 
correct object type in advance. A programmer would 
have to allocate uninitialized instances of a class and 
inittali/^e them later. However, many class implcmotitois 
prohibit the creation of uninitialized instances of thou 
class. 

Second, most code is not written with pioallocation 
in mind. Therefore, when integrating code that has pic- 
allocated resources with existing code ttiat has not prc- 
allocated any resources, there is no way to direct the 



existing code to use the resources that may have been 
preallocated. 

Third, preallocaiion of resources prohibits intelli- 
gent management by the system. From the perspective 

5 of the system, once a resource has been allocated, the 
resource is considered to be in use. Therefore, even if 
some of the resources that have been allocated are not 
actually in use, the system may not manage the allocat- 
ed resources (e.g. , temporarily loan some of the allocat- 

10 ed memory to a separate operation). 

SUMiVIARY OF THE INVENTION 

One embodiment of the invention provides a meth- 
'5 od (or managing resources in a computer system. Ac- 
cording to one embodiment of the invention, a resource 
manager receives a first request of a first operation. The 
first request identifies a first resource and specifies an 
amount of the first resource needed to execute the first 
20 operation. In response, a resource manager determines 
if the amount of the first resource requested by the first 
request is available to be reserved. In response to the 
amount of the first resource requested by the first re- 
quesi being available to be reserved, the resource man- 
^5 ager leservcs the amount of the first resource requested 
by the first request in advance of allocating the first re- 
source to the first operation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

30 

One embodiment of the invention is illustrated by 
way of example and not limitation in the figures of the 
accompanying drawings, in which like references indi- 
cate similar elements, and in which: 
^5 Figure 1 illustrates a computer system capable of 
implomonting one embodiment of the invention. 

Figure 2a is a flow diagram describing the steps in 
one embodiment of the invention. 

Figure 2b is a flow diagram describing the steps in 
-^0 one cmlDodiment of the invention. 

DETAILED DESCRIPTION 

A moihod IS described for reserving resources in 
■iS .u'lv .nco ol aliocaiing the resources. 

: -nofting to Figure 1, the computer system upon 
v.! ' tin: one embodiment of the invention can be im- 
i. • • • niod IS shown as 100 Shown in the memory 104 
■■'r^'.'ior system 100 is an operating system 110. 
• ••niiots the execution of user application pro- 
.' •! provides services such as scheduling, data 
*.* .! v^niiol and other data management re- 

■ : n iho opciating system is the resource 
* ' .. winch IS a control program responsible 
-iiion of the computer system's resources 
Hi :o(nanHgor 11 2 could alternatively be stored 
' ' I (Mfyitior -readable medium, such as a magnetic 
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disk, accessible via the disk drive unit 120, shown in- 
cluded in the computer system of Figure 1 . The resource 
manager 112 could also be stored on a separate com- 
puter system and accessed over a network connection 
to the computer system 100 via the network device 122 
also shown included in the computer system 100. 

Also Included in the memory 1 04 is the multi-thread- 
ed program 1 1 5. which as shown, is presently being ex- 
ecuted. In modern interactive software, a single pro- 
gram can be made up of multiple control flows, com- 
monly referred to as "threads of conlror (threads). 
Threads extend the concept of switching between sev- 
eral different running programs (I.e. processes), to 
switching between several different functions executing 
simultaneously within a single program (i e., multitask- 
ing in a single program). As a result, higher throughput 
and better performance of a single program is achieved 
because one thread can run while another thread is 
sleeping (e.g.. fetching data from a disk). 

IVIultiple threads belonging to one program share 
the same address space, however each thread does 
have Its own program counter (PC), register set, and 
stack. As a result, the overhead of switching between 
threads (e.g. saving the state of a few registers a stack 
pointer a program counter etc.) is considerably less 
than the overhead incurred when switching between 
processes (e.g. saving the state of virtual memory 
maps, file descriptors, etc.). 

Computer resources are allocated to each thread in 
order to complete the respective operation associated 
with each thread. The resources allocated could include 
random access memory, network bandwidth, a display, 
a printer, or any other device of the computer system 
that can be allocated to an operation of a running pro- 
gram. 

In order to obtain the resources needed to complete 
execution of the operation, each thread submits a re- 
quest to the resource manager 112. The resource man- 
ager reads the request to determine the resource re- 
quested and the amount requested. The resource man- 
ager then reads the Resource Status Table 125 (RST) 
to determine if the requested amount of the requested 
resource is available. 

In one embodiment, the RST includes an available 
indicator for each resource, which shows how much of 
that particular resource is available to be reserved (e 
g., 127). In an alternative embodiment, a reserved indi- 
cator could be used to show the amount of each re- 
source that is presently reserved. 

If the requested amount of the requested resource 
is available, the resource manager reserves the re- 
quested amount of the requested lesource (hcfcinafior 
referred to as the reserved resource) On the other 
hand, if the requested amount of the requested resource 
is not available, the requesting thread may choose not 
to begin its operation. 

When reserving the requested amount of the re- 
quested resource, the resource manager inserts an en- 



try into the Reservation Table 130 for the reserved re- 
source. Each entry in the Reservation Table identifies 
the reserved resource, the amount of the resource re- 
served, and the thread that has reserved the resource. 
5 In addition, the resource manager updates the RST to 
reflect the reservation. 

Sometime after the reservation, the reserved re- 
source is allocated to the thread for which it has been 
reserved. By reserving a part of a resource for a request 
10 prior to allocating the resource to the request, the thread 
requesting the resource is certain to have enough of the 
resource to complete its operation. 

When the reserved resource is allocated to the re- 
questing thread, the resource manager updates the !n- 
'5 use Table 145 (IT) to show the resen/ed resource is 
presently allocated to a thread. When a resource has 
been allocated to a thread it is assumed, from the per- 
spective of the resource manager and the computer sys- 
tem, that the amount of the resource that has been al- 

^0 located is in use. 

In alternative embodiments, the invention provides 
a manner of intelligently managing the resources that 
have been reserved. For example, l^y separating the 
reservation of resources from the allocation of rescurc- 

^5 es. a system may know which resources are currently 
being used and which resources are not being used. As 
a result, resources not in use. but reserved by a thread 
can be temporarily loaned to a higher priority operation. 
Referring to Figure 2. a flow diagram is illustrated 

^0 describing the steps of the performing the invention ac- 
cording to one embodiment. In block 202, a thread sub- 
mils a request to the resource manager to obtain the 
resources need to complete execution of an operation 
associated with the thread. In one embodiment, each 

^5 request of a thread identifies a resource, the amount re- 
quested, and the prionty of the request. In alternative 
embodiments, the requesting thread may also include 
its own priority relative the other threads of the program 
115. 

^0 After reading the request of a thread, in decision 
block 204. the resource manager reads the available in- 
dicator (eg. 127) of the Resource Status Table 125 
(RST) to determine if the requested amount of the re- 
quested resource is available to be reserved. In an al- 

^5 tcrnative embodiment, in decision block 204 the re- 
source manager may also determine whether the 
amount of the requested resource is available to be re- 
served IS below a predetermined threshold, wherein the 
amount of ihe requested resource available to be re- 

>o served would be considered relatively low. 

II the requested amount of the requested resource 
is availHble or in the atlornative embodiment, exceeds 
the piodcjcrrninod threshold in block 206 the resource 
mHiiagcf r csoi ves Ihe requested amount of the request- 

•5 od resource (hereinafter referred to as the reserved re- 
souice) 

More specifically, the resource manager inserts an 
entry 1 38 into Ihe Resen/ation Table 1 30. In one embod- 
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imenl. each entfy of ihe Reservation Table icJcniihes iho 
requested resource 131. Ihe amount of the resource that 
is being reserved for the requesting thread 132. the 
thread that has requested the resource 133. the priority 
of the request as normal or non-essential 1 34. and pos- 
sibly indicate the priority of the requesting thread 135. 
In alternative embodiments. Ihe entries of the RST may 
vary within the scope of the Invention, so long as they 
indicate which resources have been allocated. fVloreo- 
ver the priority levels other than normal or non-essential 
can be assigned to the request of each requesting 
thread without deviating from the scope of the invention. 

In block 208, the resource manager updates the 
available indicator 127 of the RST to show that the re- 
served resource is not available to be reseived. 

In block 210, sometime after the resource manager 
has reserved the requested amount of the requested re- 
source, the reserved resource is dynamically allocated 
to the respective thread for which it has been reserved. 
The dynamic allocation is defined as allocating portions 
of the reserved resource to the requesting thread as the 
reserved resource is needed by the requesting thread. 

In response to part of the reserved resource being 
dynamically allocated to the requesting thread, in block 
212. the resource manager updates the In-use Table 
145 to show the amount of the reserved resource that 
is presently allocated to the thread which has requested 
the resource. In one embodiment, each entry of the In- 
use Table may indicate the resource 146. the amount 
presently allocated 147, and thread to which the re- 
source has been allocated 148. 

For example, if a threadi has reserved 100 kilo- 
bytes (K) of memory, but initially is only allocated 25K. 
the entry for threadi 's In-Use table will indicate only 25K 
has been allocated to threadi. fVloreover. if threadi is 
initially allocated 1 0OK of memory and part way through 
its execution, threadi is finished with 50K of the memory, 
the resource manager may update threadl's entry to 
show that only 50K of memory is now allocated to 
threadi . 

In one embodiment, if the resource manager deter- 
mines in decision block 204 that the requested amount 
of the requested resource is not available. 0( in the al- 
ternative embodiment, determines that the amount 
available is below the predetermined threshold, the re- 
source manager attempts to suspend a prior request. In 
an alternative embodiment, when the requested re- 
source is below the predetermined level, the rosouicc 
manager may be programmed to reject the request if 
Ihe request is non-essential or the priority of the thread 
requesting the resource is below a prodctorf ninod level 
of priority. 

When attempting to suspend a pnor request in 
block 214. the resource manager reads the Rcseivalion 
table to find a prior request of a separate thread that has 
already resen/ed enough of the requested icsourco lo 
satisfy the present request which has been unable to 
reserve part of the requested resource In an alternative 



embodiment, the resource manager may attempt to sus- 
pend a group of prior requests, which together have re- 
served enough of the requested resource to satisfy the 
present request. 

5 Once the resource manager has found a prior re- 
quest which has reserved enough of the requested re- 
source to satisfy the present request, in block 216. the 
resource manager reads the In-use Table to determine 
how much of the requested resource has been allocated 

^0 to the prior request. If the requested resource is unallo- 
cated to the prior request, or if enough of the requested 
resource to satisfy the present request is unallocated to 
the prior request, in decision block 218. the resource 
manager performs a logical comparison between Ihe 

'5 prior request and the present request. Otherwise, in 
block 217, the resource manager rejects the present re- 
quest. 

The logical comparison performed by the resource 
manager in block 218 is predetermined. The logical 

20 comparison, for example, may compare the priority of 
the present request with the priority of the prior request, 
and/or the priority of the present requesting thread to 
the priority of the prior requesting thread. 

If the prior request exceeds the present requesi in 

2S Ihe comparison, in block 220. the resource manager v/ill 
reject the present request or attempt to suspend another 
prior request. On the other hand, if the present requost 
exceeds the prior request in the logical comparison in 
block 222 the resource manager will temporarily siis- 

^0 pend the prior request and insert an entry in the reser- 
vation table for the present request. Suspending the pri- 
or request is transparent to a user of the computer sys- 
tem 

In one embodiment, the entry of the present request 

^5 in the Reservation Table will include a pointer 1 37 to the 
suspended pnor request. As a result, when the present 
request is linished with the requested resource, the re- 
source manager will read the pointer to determine which 
pnor request to unsuspend. Moreover, the entry of the 

-^0 suspended request in the Reservation Table, may in- 
clude a field 136 that is set lo indicate the respective 
request is presently suspended. 

Consider the example shown in the memory of Fig- 
ure 1 The third thread 138 submitted a request to the 

-^5 (Gsourcc manager to obtain 150K of memory The re- 
source irianagcrs read the RST and determined that all 
of memory has been reserved. The resource manager 
then road the reservation table and saw that the second 
thread 139 has reserved 150K of memory, enough to 

50 satisfy the request of the third thread 139. 

Tlio resource manager then compared the priority 
of the third Ihi cad's (cqiicst (or memory (norinal) with 
ihe piiOMly ol Iho second thread's rociucst for memory 
(non-ossenliat) The resource manager may also have 

ss compared Iho pnonly of the third request (2nd) to the 
piiotiiy of the second requesi (9th) 

After the resource manager had determined the 
Ihud thread's lequest exceeded the second thread's re- 
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quest. Ihe resource inanager then road the In-use tdble 
and determined that no memory had been allocated to 
the second thread. As a result, the resource manager 
suspended the request of the second thread 139 and 
inserted an entry into the Reservation Table for the re- 
quest of Ihe third thread 1 38. 

The entry in the Reservation Table for the request 
of the third thread 139 includes a pointer to the request 
of the second thread. As a result, after the third thread 
is finished with the memory, the resource manager will 
read the pointer of the request for the third thread and 
unsuspend the second thread's request for memory, as 
is shown in blocl^ 224. 

In Ihe foregoing specification the invention has 
been described with reference to specific exemplary 
embodiments thereof. It will, however be evident that 
various modifications and changes may be made there- 
to without departing from the broader spirit and scope 
of the invention. For instance, where it has been shown 
that the resource manager, including the RST, the In- 
use Table, and the Reservation Table are in memory 
104, these items may also be stored on a magnetic or 
optical disk and accessed via the dist< drive 120. 

The specification and drawings are, accordingly to 
be regarded in an illustrative rather than restrictive 
sense. I\/1oreover, the following claims indicate the 
scope of the invention, and all variations which come 
within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 

Claims 

1. A computer-implemented method for managing re- 
sources in a computer system comprising the steps 
of: 

a resource manager receiving a first request of 
a first operation, said first request identifies a 
first resource and specifies an amount of the 
first resource needed to execute the first oper- 
ation: 

the resource manager determining if the 
amount of the first resource specilied by the 
first request, is available to be reserved and 
in response to the amount of the Mist resource 
specified in the first request being available to 
be reserved, the resource manager reserving 
the amount of the first resource specified in Ihe 
first request in advance of allocating the firs! re- 
source to the first operation. 

2. The computer-implemcnied method of claim 1 
wherein the first operation is a first thrcnd. said tirst 
thread is one of a set of threads belonging to one 
program, said set of threads sharing one address 
space, and each thread of said set of threads is al- 
located an individual program counter 



3. The computer-implemented method of claim 2, fur- 
ther including Ihe step of: 

in response to ihe amount of the first resource 
being unavailable to be reserved, the resource 
manager rejecting the first request. 

4. The computer-implemented method of claim 2. 
wherein the resource manager includes a resource 
status table, said resource status table indicates an 
amount of the first resource available to be reserved 
by a thread: 

'said resource manager includes a reservation 
table, said reservation table stores resource 
reservations for the set of threads, wherein 
each entry in the reservation table identifies a 
resource, an amount of the resource reserved, 
a thread for which the resource has been re- 
served, and a priority of the request of the 
thread for which the resource has been re- 
served, and 

said resource manager further includes an in- 
use table, said in-use table indicates an amount 
of a resource having been allocated to a thread. 

5. The computer-implemented method of claim 4, 
wherein the step of determining if the amount of the 
first resource specified by the first request is avail- 
able, further includes reading the resource status 
table to determine if the amount of the first resource 
specified by the first request, is available to be re- 
served. 

6. The computer-implemented method of claim 5. 
wherein the step of the resource manager reserving 
further includes the steps of: 

inserting an entry into Ihe resen/ation table: and 
updating the resource status table to indicate 
the amount of the first resource specified in the 
first request is unavailable to be reserved. 

7. The computer-implemented method of claim 6, fur- 
Ihcr including Ihe step of: 

dynamically allocating at least a part of the 
lust resource to the first thread, wherein the re- 
source manager updates the in-use table to indicate 
the part of the lirsl resource presently allocated to 
the first thread. 

50 

8. The computer-implemented method of claim 7. fur- 
ther including Iho stops of. 

in response to Ihe first thread being finished 
with the first resource, updating Ihe resource 
status table to indicate an amount of the first 
resource allocated to the first thread is availa- 
ble to be reserved. 
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and updating the in-use table lo indicate the 
amount of the first resource allocated to the first 
thread is available lo be allocated. 

9. The connputer-innplennented method of claim 8. 5 
wherein the step of the resource manager determin- 
ing if the amount of the first resource specified. by 
the first request is available further includes the 
steps of: 

the resource manager reading the resource 
status table to determine if an amount of the first 
resource available to be reserved is below a prede- 
termined threshold. 



ond thread exceeding the first request of the first 
thread in the logical comparison, the resource man- 
ager rejecting the first request of the first thread. 

1 4. The computer-implemented method of the claim 1 3. 
wherein the resource manager is part of an operat- 
ing system of a limited resource computer system. 

1 5. A computer-readable medium having stored there- 
on a plurality of sequences of instructions, said se- 
quences of instructions including instructions 
which, when executed by a processor, cause said 
processor to perform the steps of: 



10. The computer-implemented method of claim 9, fur- 
ther including the step of: 

in response to the amount of the first resource 
available to be reserved being below the predeter- 
mined threshold and the priority of the first request 
being nonessential or a priority of first thread being 
below a predetermined priority, the resource man- 
ager rejecting the first request 

11. The computer-implemented method of clainn 10 
wherein the step of the resource manager determin- 
ing if the amount of the first resource specified by 
the first request is available to be reserved, further 
includes the steps of: 

in response to the amount of the first resource 
specified by the first request being unavailable 
or the amount of the first resource available to 
be reserved being below the predetermined 
threshold, the resource manager pei forming a 
predetermined logical comparison of the first 
request of the first thread to a second request 
of a second thread, said resource manager 
having reserved at least a pan of the first re- 
source for the second request in advance of al- 
locating the first resource to the second thread' 
and 

in response to the first request of the first thread 
exceeding the second request of the second 
thread in the logical cofnparison. the resource 
manager temporarily suspending the second 
request of the second thread and reserving at 
least a part of the first resource for the first re- 
quest of the first thread 

12. The computer-implemented method of claim n , fur- 
ther comprising the steps of 

unsuspending the second request of the sec- 
ond thread after the first thread is linishod with the 
first resource. 

13. The computer-implemented method of claim 12. 
further includes the step of. 

in response lo the second lequost of the soc- 



'5 receiving a first request of a first operation, said 

first request identifies a first resource and spec- 
ifies an amount of the first resource needed to 
execute the first operation: 
determining if the amount of the first resource 

20 specified by the first request, is available to be 

reserved: and 

in response to the amount of the first resource 
specified in the first request being available to 
be resotved. reserving the amount of the first 
-5 resource specified in the first request in ad- 

vance of allocating the first resource to the first 
operation. 

1 6. The computer-readable medium of claim 1 5. where- 
^0 in the first operation is a first thread, said first thread 

IS one of a set of threads belonging to one program, 
said set of threads sharing one address space, and 
each thread of said set of threads is allocated an 
individual program counter 

35 

17. The computer-readable medium of claim 16. further 
having stored thereon additional instructions which, 
when executed by a processor cause said proces- 
sor to perform the step of: 

-^0 in response to the amount of the first resource 

being unavailable to be reserved, rejecting the first 
request. 

18. The coiTiputer-readable medium of claim 16, further 
-^5 having stored thereon a resource manager, the re- 
source manager includes a resource status table, 
said resource status table indicates an amount of 
the first resource available to be reserved by a 
thread. 

50 

SHid resource manager includes a reservation 
ial:)le. said (cservation table stores resource 
reservations for the set of threads, wherein 
each entry in the reservation table identifies a 
resource, an amount of the resource reserved, 
a thread for which the resource has been re- 
served, and a priority of the request of the 
thread for which the resource fias been re- 
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served, and 

said resource manager further includes an in- 
use table, said in-use table indicates an amount 
of a resource having been allocated to a thread. 

19. The computer-readable medium of claim 18, where- 
in the step of determining if the amount of the first 
resource specified by the first request is available, 
further includes reading the resource status table to 
determine if the amount of the first resource speci- 
fied by the first request, is available to be reserved. 

20. Thecomputer-readablemediumofclaim 19, where- 
in the step of the resource manager reserving fur- 
ther includes the steps of 

inserting an entry into the reservation table: and 
updating the resource status table to indicate 
the amount of the first resource specified in the 
first request is unavailable to be resen/ed. 

21. The computer-readable medium of claifn 20, further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of: the step of: 

dynamically allocating at least a part of (he 
first resource to the first thread, wherein the re- 
source manager updates the in-usc table to indicate 
the part of the first resource presently allocated to 
the first thread. 

22. The computer-readable medium of claim 2r further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of* 

in response to the first thread being finished 
with the first resource, updating the resource 
status table to indicate an amouni of the (irst 
resource allocated to the first thread is availa- 
ble to be reserved, 

and updating the in-use table to indicate the 
amount of the first resource allocated to the tirst 
thread is available to be allocated. 

23. The computer-readable medium of claim 22, whore- 
in the step of determining if the amouni of the lirst 
resource specified by the first request is available 
further includes the steps of: 

the resource manager reading the resource 
status table to determine if an amouni ol the first 
resource available to be reserved is below h prodo- 
termined threshold 

24. The computer-readable medium of claim 23, further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor to perform the step of 



in response to the amount of the first resource 
available to be reserved being below the predeter- 
mined threshold and the priority of the first request 
being nonessential or a priority of first thread being 
s below a predetermined priority, the resource man- 
ager rejecting the first request. 

25. The computer-readable medium of claim 23. where- 
in the step of determining if the amount of the first 

10 resource specified by the first request is available 
to be reserved, further includes the steps of: 

in response to the amount of the first resource 
specified by the tirst request being unavailable 
or the amount of the first resource available to 
be reserved being below the predetermined 
threshold, the resource manager performing a 
predetermined logical comparison of the first 
request of the first thread to a second request 
of a second thread, said resource manager 
having reserved at least a part of the first re- 
source for the second request in advance of al- 
locating the first resource to the second thread: 
and 

in response to the first request of the first thread 
exceeding the second request of the second 
thread in the logical comparison, the resource 
manager temporarily suspending the second 
request of the second thread and reserving at 
least a part of the first resource for the first re- 
quest of the first thread. 

26. The computer-readable medium of claim 25, further 
having stored thereon additional instructions which. 

^5 when executed by a processor, cause said proces- 
sor to perform the step of: 

unsuspending the second request of the sec- 
ond thread after the first thread is finished with the 
first resource. 

40 

27. The computer-readable medium of claim 26, further 
having stored thereon additional instructions which, 
when executed by a processor, cause said proces- 
sor 10 perform the step of: 

■^^ in response to the second request of the sec- 

ond thread exceeding the first request of the first 
thread in the logical comparison, the resource man- 
ager roiecting the first request of the first thread 

50 28. The computer-readable medium of the claim 27 
wherein Iho resource manager is part ol an operat- 
ing system ol a limited resource computer system 

29. A computer system configured to manage resourc- 
55 es the computer system comprising of: 

a resource manager configured to receive h 
first request of a first operation, said first re- 
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quest identifies a first resource and specilies an 
amount of the first resource needed to execute 
the first operation; 

the resource manager furtfier configured to de- 
termine if the amount of the first resource spec- 
ified by the first request, is available to be re- 
served: and 

the resource manager further configured to re- 
serve, In response to the amount of the first re- 
source specified In the first request being avail- 
able to be reserved, the amount of the first re- 
source specified in the first request in advance 
of allocating the first resource to the first oper- 
ation. 

30. The computer system of claim 29. wherein the first 
operation is a first thread, said first thread is one of 
a set of threads belonging to one program, said set 
of threads sharing one address space, and each 
thread of said set of threads is allocated an ifidivid- 
ual program counter. 

31. The computer system of claim 30, wherein the re- 
source manager is further configured to reject the 
first request in response to the amount of the first 
resource being unavailable to be reserved 

32. The computer system of claim 30, wherein the re- 
source manager includes a resource status table, 
said resource status table indicates an amount of 
the first resource available to be reserved by a 
thread: 



specified In the lirsl request. 

35. The computer system of claim 34, wherein the re- 
source manager is configured to dynamically allo- 
5 cate at least a part of the lirst resource to the first 
thread and update the in-use table to indicate the 
part of the first resource presently allocated to the 
tirst thread. 

10 36. The computer system of claim 35. wherein the re- 
source manager is configured to update. In re- 
sponse to the first thread being finished with the first 
resource, the resource status table to Indicate an 
amount of the first resource allocated to the first 

'5 thread Is available to be reserved, and update the 
In-use table to indicate the amount of the first re- 
source allocated to the first thread is available to be 
allocated. 

^0 37. The computer system of claim 36, wherein the re- 
source manager is configured to read the resource 
status table to determine if an amount of the first 
resource available to be rosen/ed is below a prede- 
lormlned threshold. 

25 

38. The computer system of claim 37. the resource 
manager is configured to reject the first request in 
response to the amount of the first resource avail- 
able to be reserved being below the predetermined 
30 threshold and the priority of the first request being 
nonessential or a priority of first thread being below 
a predetermined priority. 



said resource manager Includes a reseivation 
table, said reservation table stores resource 
reservations for the set of threads, wlierein 
each entry in the reservation table identifies a 
resource, an amount of the resource reserved, 
a thread for which the resource has been re- 
served, and a priority of the request of the 
thread for which the resource has been re- 
served, and 

said resource manager further includes an in- 
use table, said In-use table indicates an amount 
of a resource having been allocated to a thread 

33. The computer system of claim 32. wherein the re- 
source manager is configured to read the resource 
status table to determine If the amount of the first 
resource specified by the first request Is available 
to be reserved. 

34. Thecomputer system of claim 33 wherein resource 
manager Is configured to insert an entry into the res- 
ervation table and update the resource status table 
to indicate the amount of the tirst resouice specified 
in the first request is unavailable to be reserved, in 
order to reserve the amount of the lirst resource 



39. The computer system of claim 37, wherein the re- 
^5 source manager Is configured to perform, in re- 
sponse to the amount of the first resource specified 
by the first request being unavailable or the amount 
of the first resource available to be reserved being 
below the predetermined threshold, a predeter- 

-to mined logical comparison of the first request of the 
lirst thread to a second request of a second thread, 
said resource manager having reserved at least a 
part of the first resource for the second request in 
advance of allocating the first resource to the sec- 

-^5 ond thread, and 

the resource manager further configured to 
temporarily suspend, In response to the first request 
of the hrst thread, exceeding the second request of 
the second thread In the logical comparison, the 

50 second request of the second thread and reserve 
at least a part of the lirst resource for the first re- 
quest of tlio first thread. 

40. The computer system of claim 39. wherein the re- 
55 souico iTirifirigcr configured to unsuspend the sec- 
ond icquest of the second thread after, the first 
thiead is finished with the first resource 
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The computer syslem of claim 40. wherein the re- 
source manager is configured lo reject tlie first re- 
quest in response lo ttie second request of the sec- 
ond thread exceeding the first request of the first 
thread in the logical comparison. 5 

The computer syslem of the claim 41. wherein the 
resource manager is part of an operating syslem of 
a limited resource computer system. 
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